This is not an article about service-oriented architecture (SOA); neither is it a business process management (BPM) article. This article is about how business automation can change the way you create software.
At a first, developers and architects tend to associate the use of BPM suites (or business-oriented architecture) with SOA. This behavior immediately leads to an incorrect bias about the subject.
C-suite executives understand: Transform—or be suppressed by new, disruptive, technology-driven startups. In 2019, business automation is a key transformation that executives will seek in order to improve business performance and lower costs. However, some technology teams are not very open to it. Why?
In the past, BPM suites have been used as big centralized orchestrators for services, external systems, and human tasks. JBoss SOA Platform, released in 2008, is an example of such an integration platform. Unfortunately, this kind of application does not fit new cloud- and microservices-oriented architectures. The good news is that business automation evolved and can help teams to reach the next step in DevOps: BizDevOps.
Business automation in 2019
Since it is never too late to learn something new, if I must sum up, here is what every architect and developer should know:
Business automation is about improving manual tasks or manual decisions by automating and decoupling business logic (rules and flows) from application code. It is about bringing the business team closer to the development cycle (BizDevOps) and, consequently, being able to address customer feedback more quickly.
Here are important points about the most recent technical advantages of using a process-driven architecture by way of products such as Red Hat Process Automation Manager (RHPAM):
- Extract business logic from the application code (which totally fits within a microservice architecture).
- Nourish a new culture for the development cycle: the business team can understand and be responsible for authoring business assets, which are converted into code (more on this later).
- Rules and processes can have an independent and automated (pipeline) deployment and delivery lifecycle.
- Advanced dashboards with business information can be provided so C-suite executives can make decisions regarding the company's future.
- Applications can be delivered without heavy code programming.
But you might ask, "How can non-technical business analysts come closer to the technology team? They can't code!?"
Developers create code. Business analysts create business assets.
Business ideas are the reason why software is created. Therefore, it is understandable that the knowledge that gives rise to software resides within the business analyst team. And it is fair that business analysts are the ones who should be responsible for maintaining business rules and processes (and I do not mean using Microsoft Word).
But how can a business analyst create consumable business code?
Specifications such as Business Process Model and Notation 2 (BPMN2), Case Management Model and Notation (CMMN), and Decision Model and Notation (DMN) allow analysts to create assets using business concepts with intuitive tools. Under the covers, such tools convert these assets to code; create and maintain the code as Maven projects; compile the code as a Knowledge Java Archive (KJAR); and deploy the code on Process Engine, a component from Red Hat Process Automation Manager responsible for executing the business assets created using Business Central.
You can speak the same language
Analysts have been using BPM notation fluently for business process modeling. Now, Red Hat Process Automation Manager has released support for modeling and processing of Case Management (dynamic flows) and Decision Modeling Notation (DMN). The following Decision Model was created with the DMN Modeler (available in the tech preview of version 7.2):
Although some developers might not understand the complete rule at a first sight, those who have other roles and are involved with decision management can easily read decision diagrams. In other words, they will feel comfortable while designing business rules and decision flows (without coding!).
A friendly interface such as the Red Hat Process Automation Manager component called Business Central is what enables business users to work side by side with developers for the creation of modern applications.
Don't be confused: This is not orchestration. This is a graphical representation of business rules. A Decision Engine will be responsible for executing the rules. If you want to know more about DMN, check the Object Management Group's (OMG) website, the entity responsible for maintaining this specification.
Give it a try
If you want to try RHPAM, I suggest you follow these simple steps to run a complete authoring and execution environment on Spring Boot:
1. Access start.jbpm.org and click "Generate default business application."
2. After the download is complete, unzip the project, enter the folder, and execute the launch script:
$ unzip business-application.zip $ cd business-application-service $ launch.sh clean install
3. Access http://localhost:8090 on your browser.
In the business applications repository, there are several open source examples of business projects based on Spring Boot.
Conclusion
Business automation is not about orchestration. It is about empowering communication between silos that the DevOps culture does not reach: Tech and Business. Adding business automation to open source software is a must. An open culture promotes global knowledge building. This is why it is possible to find ample open documentation about jBPM, the upstream version of RHPAM (the enterprise version supported by Red Hat).
jBPM has an active users community supported by Red Hat engineers who are available to help anyone who needs information about business automation. Feel free to reach us on the IRC channel whenever you need (chat.freenode.net:6667, #jbpm).
Additional resources
Here are related articles available on the Red Hat Developer blog:
Last updated: January 22, 2024